On Sat, Jun 13, 2015 at 8:12 AM, moray.cuthill@... [DynoMotion] <DynoMotion@yahoogroups.com> wrote:

 

Are there any examples for taking a persistent var from the KFlop and displaying it in KMotionCNC?

Specifically I want to show the current turret position from the relevant persistent/user var, and have it show on the screen next to the current tool slot/id value.

I think you would need to add a user interface element, and modify the application code to update it.  Persist vars 100-107 are always updated and available to the app from the bulk status message.  I haven't tried this, so YMMV.

 

Also, is there any issue with relying on While loops to wait for input changes within the ATC script? I know it could lead to a lock up if the required input doesn't happen, but is there any other major reason to avoid this technique?

I deal with this by writing a function which sets a timeout and also waits for the move to complete.  Typically, it also looks for some other conditions such as estop.  The function returns 0 if everything was OK, or -1 otherwise.  Something like this:

int wait_io_high(int io, double timeout)
{

  double T = Time_sec() + timeout;

  while (Time_sec() < T) {

    if (ReadBit(io))

      return 0;

    // examples of tests for conditions which might prevent the

    // i/o from getting set...

    if (!chan[0].Enable)

      return -1;  // X axis got disabled e.g. following error

    // any other tests required...

    // finally, be nice and don't hog the CPU...

    WaitNextTimeSlice();

  }

  return -1; // timed out

}

The important thing is to be consistent in using the wrapper functions and doing something sensible with the result, otherwise if your thread "locks up" then you'll spend a lot of time looking for the bug.  Since the C compiler doesn't support linking, putting all these little routines in a c file which you then #include into your main thread code promotes re-use and consistency.

Using the wrapper functions and handling the results can make the code look somewhat ugly, but it's better than not working. 

I would request that Tom consider adding C's setjmp()/longjmp() functions to the firmware, since it makes this sort of exception handling a lot cleaner.  Programming machine control really has to handle a lot of exceptional conditions (as you are aware) so anything which helps keep the code clean and maintainable is a plus.

 

I will probably redo the script to include timeouts, but I'd just like to get it working similar to how I had the Mach Macro working before altering things too much (If it hanged Mach, hitting stop would kill the locked macro, so it was never a major issue, but will the same work)

What's the best way to kill the ATC thread and halt

According to Tom, PauseThread() effectively kills a thread if you start it from scratch next time (rather than resuming it).

 

 KMotionCNC if a fault is detected? Would triggering an EStop be the simplest option?

I found that telling K-CNC to estop caused too much pain.  It goes and kills every thread on the kflop.  This may be what you want, but it may be a bit drastic.  I prefer to use the "halt" command, which stops the g-code from proceeding but leaves threads running on the kflop.

Regards,

SJH

 

Thanks,

Moray